home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000007_owner-urn-ietf _Fri Mar 7 23:30:24 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  4KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id XAA19286
  3.     for urn-ietf-out; Fri, 7 Mar 1997 23:30:24 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id XAA19274
  6.     for <urn-ietf@services.bunyip.com>; Fri, 7 Mar 1997 23:30:16 -0500 (EST)
  7. Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA25724  (mail destined for urn-ietf@services.bunyip.com); Fri, 7 Mar 97 23:30:09 -0500
  9. Received: from [18.26.0.235] (gator-macip-6.lcs.mit.edu [18.26.0.235]) by lysithea.lcs.mit.edu (8.6.9/8.6.9) with ESMTP id XAA27261; Fri, 7 Mar 1997 23:30:06 -0500
  10. X-Sender: sollins@ginger.lcs.mit.edu (Unverified)
  11. Message-Id: <v03010d00af465bab9f56@DialupEudora>
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset="us-ascii"
  14. Date: Fri, 7 Mar 1997 19:31:09 -0500
  15. To: urn-ietf@bunyip.com
  16. From: "Karen R. Sollins" <sollins@ginger.lcs.mit.edu>
  17. Subject: [URN] NAPTR doc (draft-ietf-urn-naptr-03.txt)
  18. Sender: owner-urn-ietf@Bunyip.Com
  19. Precedence: bulk
  20. Reply-To: "Karen R. Sollins" <sollins@ginger.lcs.mit.edu>
  21. Errors-To: owner-urn-ietf@Bunyip.Com
  22.  
  23. Ron, Leslie, et al.,
  24.  
  25. I think this document is coming along well, but I do still have a few
  26. concerns about it.  My apologies for not getting back to you sooner on
  27. this, but I am only now really getting to the other side of my surgery.
  28. I'll just take them in order.
  29.  
  30. The first is the abstract.  It reads very nicely, but doesn't quite get
  31. across that the purpose of this document is to present an experimental UDS
  32. (URN-resolution Discovery Service).  I suggest the following minor
  33. modification to the beginning of the second paragraph;
  34.  
  35. "A UDS (URN-resolution Discovery Service) as laid out in [15] maps URNs to
  36. location information.  This document describes a new, experimental UDS
  37. scheme that provides additional mapping opportunities among URIs.  The
  38. scheme is based on a new DNS Resource Record, NAPTR (Naming Authority
  39. PoinTeR), that provides..."
  40.  
  41. Second, I don't have the Posix regular expression description here (or for
  42. that matter anywhere in my office).  I suspect that is true of many people.
  43. For completeness, is there a way that a summary of it can be provided as an
  44. appendix?  This would certainly enhance the document's completeness.
  45.  
  46. (This is an area where I expect the IESG may have some problems, but I'm
  47. not sure how to address them.  I've said this before, but I don't know
  48. whether I've done it in email.  The problem is that the IESG is well aware
  49. of the problems of using regular expressions in a widely distributed
  50. system.  The very negative experience comes from sendmail, in which the
  51. regular expressions were/are much more local.  And, even in that case, it
  52. is extremely difficult to get correct, leaving "the system" extremely
  53. fragile.  In this case, not only must the regular expression be correct,
  54. but in many cases will be dependent on others getting their regular
  55. expressions correct.  I expect there to be significant difficulty both in
  56. getting this sort of thing to be reasonably stably correct and convincing
  57. the IESG of that.  The problem I have here is that I don't know what to
  58. suggest, so mostly I'm expressing a concern.)
  59.  
  60. Third, I am still unhappy the treatment of security, both for myself and
  61. because it is my understanding that the IESG is becoming more and more
  62. picky about security requirements for documents.  The very brief discussion
  63. at the end does not convince me that that a reasonably complete set of
  64. security threats has been considered here, nor that the question of whether
  65. DNSSEC will address them has been studied.  I do not think that NAPTR needs
  66. to be extremely ruggedized with respect to security, but I do think that as
  67. more and more security problems are made public in the Wall Street Journal,
  68. New York Times and our more local newspapers, it becomes more and more
  69. important for us as the engineers of these more public mechanisms to
  70. understand and make public the dimensions in which and degrees to which our
  71. mechanisms can be trusted.  What we need to do is be quite specific about
  72. what it will and won't do, and that brief section at the end, just doesn't
  73. quite do it for me.
  74.  
  75. Of course, this is just one person's opinion.  If the consensus of the
  76. group is to move ahead with putting the document as is up to the IESG, then
  77. go ahead and try.
  78.  
  79.             Karen
  80.  
  81.